Перейти к основному содержимому

5.13. Работа с данными

ДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ
Разработчику Архитектору

Работа с данными​

Работа с базами данных в Rust охватывает два основных направления: взаимодействие с реляционными (SQL) и нереляционными (NoSQL) системами хранения, а также обработка структурированных форматов данных, таких как JSON и XML. Каждое из этих направлений имеет свои инструменты, библиотеки и рекомендованные практики.

Обработка структурированных данных: JSON и XML​

Перед сохранением или после извлечения данных из базы часто требуется сериализация или десериализация. Rust предоставляет мощные средства для этого через экосистему serde.

Библиотека serde является стандартом де-факто для работы с сериализацией в Rust. Она позволяет преобразовывать структуры Rust в JSON, XML, YAML, TOML и другие форматы, а также выполнять обратное преобразование. Serde работает на основе макросов, которые автоматически генерируют код для сериализации и десериализации, исходя из определения структуры данных.

Для работы с JSON используется crate serde_json. Он поддерживает как парсинг строки в структуру Rust, так и сериализацию структуры в строку или поток байтов. Типажи Serialize и Deserialize применяются к пользовательским структурам с помощью атрибута #[derive(Serialize, Deserialize)]. Это гарантирует, что соответствие между полями структуры и ключами JSON проверяется на этапе компиляции.

Пример:

use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
struct User {
    id: u32,
    name: String,
    email: String,
}

Такой подход обеспечивает безопасность: попытка получить поле, которого нет в JSON, или передать неверный тип данных приведёт к ошибке на этапе десериализации, а не к неопределённому поведению во время выполнения.

Для XML применяется crate serde_xml_rs или quick-xml. Quick-xml предлагает более низкоуровневый, но быстрый интерфейс, ориентированный на потоковую обработку XML без полной загрузки документа в память. Serde_xml_rs, напротив, интегрируется с serde и позволяет использовать те же структуры, что и для JSON, но с XML-разметкой. Это удобно при работе с API, которые предоставляют данные в разных форматах.

Все эти инструменты совместимы с асинхронными средами выполнения, такими как Tokio или async-std, что позволяет эффективно обрабатывать данные в веб-приложениях и микросервисах.

Работа с реляционными базами данных (SQL)​

Rust предлагает несколько уровней абстракции для взаимодействия с SQL-базами данных: от чистых SQL-запросов через драйверы до полноценных ORM.

Низкоуровневые драйверы​

Каждая популярная СУБД имеет свой драйвер в экосистеме Rust:

  • PostgreSQL: tokio-postgres (асинхронный), postgres (синхронный)
  • MySQL: mysql_async, mysql
  • SQLite: rusqlite (синхронный), libsqlite3-sys с обёртками для асинхронности
  • Microsoft SQL Server: tiberius

Эти драйверы предоставляют прямой доступ к протоколу базы данных. Они позволяют выполнять SQL-запросы, получать результаты, работать с транзакциями и параметризованными запросами. Параметризованные запросы защищают от SQL-инъекций, так как значения передаются отдельно от текста запроса и интерпретируются как данные, а не как исполняемый код.

Пример с tokio-postgres:

use tokio_postgres::{NoTls, Client};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let (client, connection) = tokio_postgres::connect(
        "host=localhost user=me dbname=mydb",
        NoTls,
    ).await?;

    tokio::spawn(async move {
        if let Err(e) = connection.await {
            eprintln!("connection error: {}", e);
        }
    });

    let rows = client
        .query("SELECT id, name FROM users WHERE age > $1", &[&18])
        .await?;

    for row in rows {
        let id: i32 = row.get(0);
        let name: &str = row.get(1);
        println!("{}: {}", id, name);
    }

    Ok(())
}

Такой подход даёт полный контроль над запросами и максимальную производительность, но требует ручного сопоставления строк результата с полями структур Rust.

ORM: Diesel​

Diesel — это наиболее зрелый и широко используемый ORM в экосистеме Rust. Он ориентирован на безопасность типов, производительность и предсказуемость. Diesel строится вокруг концепции «безопасного SQL»: большинство ошибок, связанных с несоответствием схемы базы данных и кода приложения, выявляются на этапе компиляции.

Diesel использует макросы и процедурные макросы для генерации типобезопасных запросов. Он поддерживает PostgreSQL, MySQL и SQLite. Основные компоненты Diesel:

  • Schema: описание таблиц базы данных в виде Rust-кода, генерируемого утилитой diesel_cli.
  • Models: структуры Rust, представляющие строки таблиц.
  • Queries: DSL (Domain Specific Language) для построения запросов, который компилируется в корректный SQL.

Diesel разделяет понятия schema и model. Schema описывает структуру таблицы, а model — бизнес-логику и преобразования. Это позволяет избежать дублирования и сохранить гибкость.

Пример модели и запроса:

// schema.rs (генерируется)
table! {
    users (id) {
        id -> Integer,
        name -> Text,
        email -> Text,
    }
}

// models.rs
#[derive(Queryable)]
pub struct User {
    pub id: i32,
    pub name: String,
    pub email: String,
}

// Использование
use diesel::prelude::*;
use crate::schema::users;

fn find_user_by_email(conn: &mut PgConnection, email: &str) -> QueryResult<User> {
    users::table
        .filter(users::email.eq(email))
        .first(conn)
}

Diesel проверяет, что поле email существует в таблице users, что оно имеет тип Text, и что сравнение с &str допустимо. Если изменить схему базы данных без обновления кода, компиляция завершится ошибкой.

Diesel не поддерживает асинхронность напрямую. Он предназначен для синхронных приложений или для использования в пуле потоков внутри асинхронного контекста. Это ограничение связано с архитектурными решениями, принятыми на ранних этапах разработки, когда асинхронность в Rust ещё не была стандартизирована.

Diesel применяется в проектах, где важна строгая проверка типов, предсказуемость и производительность: системные сервисы, финансовые приложения, embedded-системы с базами данных, CLI-инструменты.

ORM: SeaORM​

SeaORM — современный асинхронный ORM, созданный с учётом особенностей современного Rust. Он полностью асинхронен, поддерживает Tokio и async-std, и ориентирован на разработку веб-приложений и микросервисов.

SeaORM использует Entity-Relationship модель, где каждая таблица представлена как Entity, а строки — как Model. Он предоставляет гибкий DSL для построения запросов, включая сложные JOIN, подзапросы, агрегации и пагинацию.

Особенности SeaORM:

  • Полная асинхронность: все операции ввода-вывода выполняются без блокировки.
  • Динамическое построение запросов: условия, сортировка, лимиты могут формироваться в зависимости от логики приложения.
  • Поддержка миграций через sea-orm-cli.
  • Интеграция с serde для автоматической сериализации моделей.
  • Генерация кода на основе существующей базы данных (reverse engineering).

Пример с SeaORM:

use sea_orm::{EntityTrait, ModelTrait, QueryFilter, DatabaseConnection};

#[derive(Clone, Debug, PartialEq, DeriveEntityModel)]
#[sea_orm(table_name = "users")]
pub struct Model {
    #[sea_orm(primary_key)]
    pub id: i32,
    pub name: String,
    pub email: String,
}

#[derive(Copy, Clone, Debug, EnumIter, DeriveRelation)]
pub enum Relation {}

impl ActiveModelBehavior for ActiveModel {}

// Использование
async fn find_user_by_email(db: &DatabaseConnection, email: &str) -> Result<Option<Model>, DbErr> {
    Entity::find()
        .filter(Column::Email.eq(email))
        .one(db)
        .await
}

SeaORM активно развивается и поддерживает последние версии Rust. Он хорошо подходит для REST API, GraphQL-серверов, фоновых задач и любых приложений, где асинхронность является ключевым требованием.

Работа с NoSQL-базами данных​

Rust также предоставляет инструменты для работы с нереляционными базами данных, хотя экосистема здесь менее зрелая, чем для SQL.

MongoDB​

Для MongoDB существует официальный драйвер mongodb, разработанный самой компанией MongoDB. Он полностью асинхронный, поддерживает все основные функции: CRUD-операции, агрегации, транзакции (в репликах), индексы.

Данные в MongoDB представлены как BSON — двоичная форма JSON. Crate bson предоставляет типы Document, Array, DateTime и другие, а также интеграцию с serde. Это позволяет легко преобразовывать структуры Rust в BSON и обратно.

Пример:

use mongodb::{Client, options::ClientOptions};
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
struct User {
    name: String,
    email: String,
}

#[tokio::main]
async fn main() -> mongodb::error::Result<()> {
    let client_options = ClientOptions::parse("mongodb://localhost:27017").await?;
    let client = Client::with_options(client_options)?;

    let db = client.database("mydb");
    let collection = db.collection::<User>("users");

    let user = User {
        name: "Alice".to_string(),
        email: "alice@example.com".to_string(),
    };

    collection.insert_one(user, None).await?;

    Ok(())
}

Redis​

Redis — популярное хранилище ключ-значение — поддерживается через crate redis (синхронный) и redis-rs с асинхронными адаптерами. Он используется для кэширования, очередей сообщений, сессий и временных данных.

Другие NoSQL-системы​

Для Cassandra существует cdrs-tokio, для Elasticsearch — elasticsearch-rs, для DynamoDB — AWS SDK for Rust. Эти драйверы обычно предоставляют низкоуровневый API, но могут быть обёрнуты в собственные абстракции при необходимости.

Выбор подхода​

Выбор между низкоуровневыми драйверами, Diesel и SeaORM зависит от требований проекта:

  • Если нужен полный контроль над SQL и максимальная производительность — используются прямые драйверы.
  • Если приложение синхронное, требует строгой проверки типов и стабильности — выбирается Diesel.
  • Если приложение асинхронное, масштабируемое, с динамическими запросами — предпочтителен SeaORM.

Все подходы совместимы с обработкой JSON/XML через serde, что обеспечивает единый стиль работы с данными на всех уровнях приложения.

Rust делает работу с базами данных безопасной, эффективной и предсказуемой. Благодаря системе типов и компилятору, многие ошибки, характерные для других языков (неправильные имена полей, несогласованность схемы, SQL-инъекции), исключаются ещё до запуска программы. Это особенно ценно в долгоживущих системах, где стабильность и надёжность имеют первостепенное значение.

Транзакции и согласованность данных​

Транзакции — ключевой механизм обеспечения целостности данных в реляционных базах. В Rust работа с транзакциями реализована как на уровне драйверов, так и через ORM. Diesel и SeaORM предоставляют удобные абстракции для управления транзакциями без необходимости писать SQL-команды BEGIN, COMMIT или ROLLBACK вручную.

В Diesel транзакции запускаются с помощью метода transaction() у соединения:

use diesel::Connection;

conn.transaction::<_, diesel::result::Error, _>(|| {
    // несколько операций
    create_user(&mut conn, &user1)?;
    create_profile(&mut conn, &profile1)?;
    Ok(())
})?;

Если любая из операций внутри замыкания вернёт ошибку, транзакция автоматически откатится. Это гарантирует атомарность: либо все изменения применяются, либо ни одно.

SeaORM использует аналогичный подход, но в асинхронном контексте:

let txn = db.begin().await?;
User::insert(user).exec(&txn).await?;
Profile::insert(profile).exec(&txn).await?;
txn.commit().await?;

Здесь разработчик явно управляет началом и завершением транзакции, что даёт гибкость при работе с распределёнными системами или вложенным логическим уровнем.

Важно помнить: транзакции блокируют ресурсы базы данных. Долгие транзакции могут привести к взаимоблокировкам (deadlocks) или снижению пропускной способности. Поэтому рекомендуется выполнять только необходимые операции внутри транзакции и не включать в неё внешние вызовы (например, HTTP-запросы).

Миграции базы данных​

Миграции — это управляемый способ изменения структуры базы данных с течением времени. Они позволяют синхронизировать схему БД с кодом приложения, особенно в командной разработке и при развёртывании в разных окружениях.

Diesel и миграции​

Diesel поставляется с CLI-утилитой diesel_cli, которая генерирует шаблоны миграций:

diesel migration generate add_users_table

Эта команда создаёт директорию с двумя файлами: up.sql и down.sql. В up.sql описывается применение изменений (например, CREATE TABLE users), в down.sql — их откат (DROP TABLE users).

Миграции применяются командой:

diesel migration run

Diesel сохраняет историю применённых миграций в служебной таблице _diesel_schema_migrations, что предотвращает повторное выполнение.

SeaORM и миграции​

SeaORM предоставляет собственный инструмент sea-orm-cli, который поддерживает как SQL-миграции, так и программные миграции на Rust:

pub struct Migration;

impl MigrationName for Migration {
    fn name(&self) -> &str {
        "m20240101_000001_create_users_table"
    }
}

#[async_trait::async_trait]
impl MigrationTrait for Migration {
    async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
        manager
            .create_table(
                Table::create()
                    .table(User::Table)
                    .col(ColumnDef::new(User::Id).integer().not_null().auto_increment().primary_key())
                    .col(ColumnDef::new(User::Name).string().not_null())
                    .to_owned(),
            )
            .await
    }

    async fn down(&self, manager: &SchemaManager) -> Result<(), DbErr> {
        manager.drop_table(Table::drop().table(User::Table).to_owned()).await
    }
}

Программные миграции на Rust имеют преимущество: они типобезопасны и могут использовать общую модель данных, определённую в основном коде. Это снижает риск рассогласования между миграцией и моделью.

Пул соединений​

Установка нового соединения с базой данных — дорогая операция. Для повышения производительности Rust-приложения используют пулы соединений. Пул создаёт набор готовых соединений при старте и переиспользует их между запросами.

Синхронные пулы​

Для Diesel часто используется r2d2 — универсальный пул соединений, совместимый с любыми драйверами, реализующими трейт ManageConnection. Пример:

use diesel::r2d2::{ConnectionManager, Pool};

type PgPool = Pool<ConnectionManager<PgConnection>>;

let manager = ConnectionManager::<PgConnection>::new(database_url);
let pool = Pool::builder()
    .max_size(15)
    .build(manager)
    .expect("Failed to create pool");

Приложение берёт соединение из пула, выполняет запрос, и соединение автоматически возвращается в пул после выхода из области видимости.

Асинхронные пулы​

Для SeaORM и других асинхронных драйверов используется bb8 — асинхронный аналог r2d2. Однако большинство современных ORM, включая SeaORM, уже встроили управление пулом внутрь. Например, при создании подключения к базе через Database::connect(), SeaORM автоматически настраивает пул с параметрами по умолчанию, которые можно настроить через ConnectOptions.

Это упрощает разработку: разработчику не нужно думать о пуле напрямую, достаточно передавать DatabaseConnection в функции.

Обработка ошибок​

Rust не использует исключения. Все ошибки возвращаются явно через тип Result<T, E>. Это особенно важно при работе с базами данных, где возможны сетевые сбои, нарушения ограничений (например, уникальность), истечение времени ожидания и другие проблемы.

Diesel определяет свой тип ошибки diesel::result::Error, который включает варианты вроде NotFound, DatabaseError, RollbackTransaction. Это позволяет точно реагировать на разные ситуации:

match find_user(conn, id) {
    Ok(user) => Ok(user),
    Err(diesel::result::Error::NotFound) => Err(UserError::NotFound),
    Err(e) => Err(UserError::Database(e)),
}

SeaORM использует тип DbErr, который также детализирован: RecordNotFound, Query, Migration, Connection и другие. Это помогает строить осмысленные ответы API или логировать ошибки с контекстом.

Хорошая практика — не пропускать ошибки базы данных на уровень пользователя без преобразования. Вместо этого их следует оборачивать в доменные ошибки приложения, чтобы не раскрывать внутреннюю структуру БД.

Лучшие практики проектирования слоя данных​

  1. Разделение ответственности
    Логика работы с базой данных должна быть изолирована в отдельном модуле или crate. Это облегчает тестирование, замену ORM и поддержку.

  2. Использование репозиториев
    Шаблон Repository позволяет абстрагировать источник данных. Интерфейс репозитория определяет методы вроде find_by_email, save, delete, а реализация может использовать Diesel, SeaORM или даже mock-объекты для тестов.

  3. Избегание N+1-запросов
    При загрузке связанных данных (например, пользователь и его посты) важно использовать JOIN или eager loading. Иначе каждый запрос к связанной сущности порождает отдельный SQL-запрос, что резко снижает производительность.

  4. Параметризованные запросы всегда
    Даже если данные приходят из доверенного источника, использование параметризованных запросов — обязательное правило. Это предотвращает SQL-инъекции и делает код чище.

  5. Тестирование с реальной базой
    Интеграционные тесты должны запускаться против реальной СУБД (часто в Docker-контейнере). Это выявляет ошибки, которые не видны при мокировании: несовместимость типов, ограничения внешних ключей, особенности поведения конкретной СУБД.

  6. Логирование запросов в разработке
    В режиме отладки полезно включать логирование всех SQL-запросов. Diesel поддерживает это через флаг --features "logging", SeaORM — через настройку ConnectOptions::log_statements.

  7. Ограничение прав доступа
    Учётная запись, используемая приложением для подключения к БД, должна иметь минимально необходимые права: только SELECT, INSERT, UPDATE, DELETE на нужные таблицы, без DDL-операций в production.

Сериализация моделей в JSON и обмен данными​

В веб-приложениях данные, извлечённые из базы, часто передаются клиентам в формате JSON. Rust позволяет легко интегрировать модели базы данных с HTTP-слоем через библиотеку serde.

Модели Diesel или SeaORM могут напрямую реализовывать трейты Serialize и Deserialize. Например:

#[derive(Queryable, Serialize)]
pub struct User {
    pub id: i32,
    pub name: String,
    pub email: String,
}

Такая структура может быть сразу преобразована в JSON с помощью serde_json::to_string() или автоматически сериализована фреймворком (например, Axum или Actix Web).

Однако на практике модель базы данных редко совпадает с API-представлением. Часто требуется:

  • скрыть внутренние поля (например, password_hash);
  • добавить вычисляемые поля (например, full_name);
  • изменить имена полей для соответствия соглашениям API.

Для этого создаются отдельные структуры — DTO (Data Transfer Objects):

#[derive(Serialize)]
pub struct UserResponse {
    id: i32,
    name: String,
    email: String,
    created_at: chrono::DateTime<Utc>,
}

impl From<User> for UserResponse {
    fn from(user: User) -> Self {
        Self {
            id: user.id,
            name: user.name,
            email: user.email,
            created_at: Utc::now(), // или из базы
        }
    }
}

Такой подход обеспечивает чёткое разделение между слоем данных и слоем представления. Он также упрощает версионирование API: можно вводить новые DTO без изменения моделей.

Валидация данных​

Валидация — обязательный этап при приёме данных от пользователя. Она выполняется до сохранения в базу и после десериализации JSON.

Rust не имеет встроенной системы валидации, но экосистема предлагает несколько решений:

  • validator — популярная библиотека, предоставляющая макросы для проверки длины строк, формата email, диапазонов чисел и пользовательских правил.
  • custom logic — ручная проверка в конструкторах или методах new.

Пример с validator:

use validator::{Validate, ValidationError};

#[derive(Deserialize, Validate)]
pub struct CreateUserRequest {
    #[validate(length(min = 2, max = 50))]
    pub name: String,

    #[validate(email)]
    pub email: String,
}

// В обработчике
let request: CreateUserRequest = serde_json::from_str(body)?;
request.validate()?;

Если валидация не проходит, возвращается структура ValidationErrors, которую можно преобразовать в понятный пользователю ответ.

Важно: валидация на уровне приложения дополняет, но не заменяет ограничения базы данных (NOT NULL, UNIQUE, CHECK). Оба уровня необходимы для надёжности.

Кэширование запросов​

Часто запрашиваемые данные (например, профиль пользователя, справочники) выгодно кэшировать, чтобы снизить нагрузку на базу.

Rust предлагает несколько решений:

  • In-memory cache: moka, dashmap, lru — для хранения данных в памяти процесса.
  • Redis: как внешний кэш, особенно в распределённых системах.

Пример с moka:

use moka::future::Cache;

let user_cache: Cache<i32, User> = Cache::new(10_000);

async fn get_user(id: i32, db: &DatabaseConnection, cache: &Cache<i32, User>) -> Result<User, Error> {
    if let Some(user) = cache.get(&id) {
        return Ok(user);
    }

    let user = fetch_user_from_db(db, id).await?;
    cache.insert(id, user.clone()).await;
    Ok(user)
}

Кэширование требует стратегии инвалидации: при обновлении данных в базе соответствующий ключ должен быть удалён из кэша. Это можно реализовать через события, триггеры или простое TTL-истечение.

Работа с большими объёмами данных​

При обработке миллионов записей важно избегать загрузки всего набора в память. Rust поддерживает потоковую обработку:

  • Diesel: метод load_in_batches() позволяет загружать данные порциями.
  • SeaORM: поддержка пагинации через Paginator.
  • Низкоуровневые драйверы: курсоры (cursors) в PostgreSQL (DECLARE CURSOR) позволяют итерироваться по результату без полной загрузки.

Пример пагинации в SeaORM:

let mut paginator = Entity::find()
    .paginate(db, 100); // 100 записей на страницу

while let Some(items) = paginator.fetch_and_next().await? {
    for item in items {
        process(item).await;
    }
}

Такой подход минимизирует потребление памяти и позволяет обрабатывать данные в реальном времени.

Для массовой вставки (bulk insert) рекомендуется использовать:

  • COPY в PostgreSQL (через tokio-postgres-copy);
  • INSERT INTO ... VALUES (...), (...), ... с ограниченным числом строк;
  • транзакции для группировки операций.

Интеграция с веб-фреймворками​

Axum​

Axum — современный веб-фреймворк, построенный на Tower и Hyper. Он отлично сочетается с SeaORM благодаря асинхронности.

Пример обработчика:

use axum::{Json, extract::State};
use sea_orm::DatabaseConnection;

async fn create_user(
    State(db): State<DatabaseConnection>,
    Json(payload): Json<CreateUserRequest>,
) -> Result<Json<UserResponse>, AppError> {
    let user = User::create(payload).exec(&db).await?;
    Ok(Json(UserResponse::from(user)))
}

Состояние приложения (включая пул соединений) передаётся через State.

Actix Web​

Actix Web использует другой подход — данные внедряются через web::Data:

use actix_web::{web, HttpResponse};

async fn get_user(
    db: web::Data<DatabaseConnection>,
    path: web::Path<i32>,
) -> Result<HttpResponse, AppError> {
    let user = User::find_by_id(path.into_inner()).one(&*db).await?;
    Ok(HttpResponse::Ok().json(user))
}

Оба фреймворка поддерживают middleware, обработку ошибок и валидацию, что делает интеграцию с базой данных прозрачной.

Сравнение производительности: Diesel vs SeaORM​

Diesel компилирует запросы в статический SQL на этапе сборки, что даёт минимальные накладные расходы во время выполнения. Он быстрее в синхронных сценариях и потребляет меньше памяти.

SeaORM генерирует SQL динамически, что добавляет небольшие накладные расходы, но обеспечивает гибкость. Его производительность достаточна для большинства веб-приложений, особенно при использовании пула соединений и кэширования.

Выбор не должен основываться только на производительности. Архитектурные требования — синхронность, типобезопасность, поддержка миграций — играют большую роль.

Безопасность при работе с базами данных​

Безопасность — неотъемлемая часть любого приложения, взаимодействующего с данными. Rust помогает избежать многих классических уязвимостей благодаря своей системе типов и принудительной обработке ошибок, но разработчик всё равно несёт ответственность за корректное проектирование.

Защита от SQL-инъекций​

SQL-инъекции возникают, когда пользовательский ввод интерпретируется как часть SQL-кода. В Rust эта проблема практически исключена при соблюдении базовых правил:

  • Все ORM (Diesel, SeaORM) используют параметризованные запросы по умолчанию. Значения передаются отдельно от текста запроса и никогда не интерполируются в строку.
  • При использовании низкоуровневых драйверов (например, tokio-postgres) следует избегать конкатенации строк для формирования SQL. Вместо этого применяются placeholders ($1, $2 в PostgreSQL; ? в SQLite/MySQL).

Пример безопасного запроса:

client.query("SELECT * FROM users WHERE email = $1", &[&email]).await?;

Даже если email содержит вредоносный код вроде ' OR '1'='1, он будет обработан как строковое значение, а не как условие.

Утечки данных​

Модели базы данных часто содержат чувствительные поля: хэши паролей, токены, внутренние идентификаторы. Чтобы избежать их случайной передачи в API:

  • Используются отдельные DTO для ответов.
  • Структуры, предназначенные только для внутреннего использования, не реализуют Serialize.
  • Включается строгий контроль доступа на уровне бизнес-логики.

Ограничение прав доступа​

Учётная запись базы данных, используемая в production, должна иметь минимально необходимые привилегии:

  • Нет прав на DROP, ALTER, CREATE.
  • Доступ только к конкретным таблицам.
  • Отсутствие возможности выполнять произвольные функции или читать системные каталоги.

Это снижает потенциальный ущерб даже в случае компрометации приложения.

Хранение учётных данных​

Строки подключения и пароли никогда не хранятся в коде. Они передаются через переменные окружения или секреты (например, Kubernetes Secrets, HashiCorp Vault). Для удобства используется библиотека config или dotenvy, которая загружает .env-файлы только в development-среде.

Тестирование слоя данных​

Тестирование — ключевой элемент надёжности. В Rust различают два типа тестов для работы с БД:

Unit-тесты​

Unit-тесты проверяют логику без реального подключения к базе. Для этого используются mock-объекты или in-memory реализации. Однако из-за строгой типизации и отсутствия динамической диспетчеризации в Rust полноценное мокирование ORM затруднено.

Поэтому чаще применяется подход: выделяется интерфейс (через трейты), а реализация подменяется в тестах:

#[async_trait]
pub trait UserRepository {
    async fn find_by_email(&self, email: &str) -> Result<Option<User>, DbErr>;
    async fn save(&self, user: User) -> Result<(), DbErr>;
}

// Реализация для SeaORM
pub struct SeaOrmUserRepository {
    db: DatabaseConnection,
}

// Mock-реализация для тестов
pub struct MockUserRepository {
    users: HashMap<String, User>,
}

Этот подход требует дополнительной абстракции, но даёт полный контроль над поведением в тестах.

Интеграционные тесты​

Интеграционные тесты запускаются против реальной СУБД. Обычно используется временная база в Docker-контейнере, создаваемая перед тестами и удаляемая после.

Последовательность действий:

  1. Запуск контейнера с PostgreSQL/MySQL через testcontainers crate.
  2. Применение миграций.
  3. Выполнение тестов.
  4. Удаление контейнера.

Пример:

use testcontainers::{clients, images::postgres::Postgres, RunnableImage};

#[tokio::test]
async fn test_user_creation() {
    let docker = clients::Cli::default();
    let image = RunnableImage::from(Postgres::default()).with_tag("15");
    let node = docker.run(image);
    let port = node.get_host_port_ipv4(5432);

    let db_url = format!("postgres://postgres:postgres@localhost:{}/postgres", port);
    let db = Database::connect(db_url).await.unwrap();

    // Выполнение миграций и тестов
}

Такой подход гарантирует, что код работает именно так, как в production.

Мониторинг и логирование​

Надёжные системы требуют наблюдаемости. При работе с базами данных важны три компонента: логирование, метрики и трассировка.

Логирование​

Все SQL-запросы и ошибки должны логироваться. Diesel поддерживает интеграцию с log и tracing. SeaORM позволяет включить логирование через ConnectOptions::log_statements(LogLevel::Debug).

В production логируются:

  • медленные запросы (например, дольше 100 мс);
  • ошибки подключения;
  • откаты транзакций.

Логи структурируются в формате JSON для удобства анализа системами вроде ELK или Loki.

Метрики​

С помощью библиотеки metrics или prometheus можно собирать:

  • количество активных соединений;
  • время выполнения запросов (гистограммы);
  • частоту ошибок.

Эти данные позволяют выявлять узкие места и планировать масштабирование.

Трассировка​

В распределённых системах запрос проходит через несколько сервисов. Для отслеживания используется OpenTelemetry. SeaORM и современные драйверы совместимы с tracing — каждый запрос может быть помечен тем же trace ID, что и HTTP-запрос, инициировавший его.

Полный жизненный цикл запроса: от HTTP до базы и обратно​

Рассмотрим типичный сценарий: клиент отправляет POST-запрос на /users с JSON-телом, сервер создаёт пользователя и возвращает 201 Created.

  1. Получение запроса
    Веб-фреймворк (Axum, Actix) принимает HTTP-запрос и извлекает тело.

  2. Десериализация
    Тело парсится в структуру CreateUserRequest через serde_json. Если формат неверен — возвращается 400 Bad Request.

  3. Валидация
    Поля проверяются на длину, формат email и уникальность (последнее — через запрос к БД).

  4. Создание модели
    На основе входных данных строится модель User (SeaORM) или NewUser (Diesel).

  5. Сохранение в базу
    Выполняется INSERT внутри транзакции. Если нарушено ограничение уникальности — возвращается 409 Conflict.

  6. Формирование ответа
    Созданная запись преобразуется в UserResponse (DTO), сериализуется в JSON.

  7. Отправка ответа
    Фреймворк отправляет 201 Created с заголовком Location и телом.

На каждом этапе возможны ошибки, и каждая обрабатывается явно через Result. Благодаря этому система остаётся устойчивой даже при неожиданных сценариях.